Device Driver function behavior on interrupt
A device driver (for devices like I2C) is typically split into an application interface and a hardware interface.

The application interface typically just puts the data you want to send to the device in a buffer, and notifies the hardware interface part of the driver that there is data to send, and then returns to the caller. Asking for data would involve checking if there is enough data already available and either waiting for the data to become available or returning it immediately.

The hardware section of the interface would take data in the write buffer and pass it to the hardware as fast as the hardware can accept it - hardware typically notifies the driver, by an interrupt to say that it either has received data to process, or it can accept more data to transmit.

There is a requirement that the hardware and application sections do not attempt to modify the shared storage buffers at the same time, and there are several ways this can be achieved.

Using interrupts is optimal, because the processor only has to do work on servicing the hardware when the hardware indicates that it is ready. To do the same thing in tasks involves a process known as 'polling' essentially asking the hardware if it is ready. You could think of this as being analogous to turning off your telephone ringer, and picking up the phone periodically to see if someone is calling.